Experimental Soft Navigation support #308
Conversation
There was a problem hiding this comment.
Hey, this is excellent work. Quite a bit to get right, thanks for the effort!
I only review the CLS changes, and I think there's a potentially cleaner way to do it. I didn't review the specifics of the other metrics since I the change would alter a lot there too, so wanted to discuss that first.
Basically:
- I think the observe() helper, which all metrics use, should be the only place where we look at navigationID and split entries whenever it changes. See: https://github.com/GoogleChrome/web-vitals/blob/main/src/lib/observe.ts#L52
- Whenever navigationID changes (or, the first time for initial nav), that helper can look up pageURL, etc, that way we have shared cache for all metrics
- Each metric implementation right now already uses helpers like onFCP, onHidden, onBFCacheRestore... in order to "finalize" and/or "reset" its metrics. I think we could have another helper like onNavigate(), which can be used to flush/reset metrics.
One tricky bit may be that the onNavigate() helper needs to be called before any new Entry that uses that navigationID, and you could have entries with different navigationID in a single PerformanceObserver callbacks, especially when using buffered entries.
That said, I think all this code made be fragile to such cases and needs careful testing.
Keep at it!
| entries.forEach((entry) => { | ||
| if ( |
There was a problem hiding this comment.
Perhaps a cleaner way to do it is to have the helper class that calls handleEntries automatically split entries based on navigationID?
Then, you dont' need to do this once per entry.
Also, that helper that does the split could call something like "finalizeAndReset", so we wouldn't need to do these tests here at all. The metric specific handlers would just get a URL and maintain a score...
WDYT?
There was a problem hiding this comment.
While that may look like cleaner code, I wonder about the performance implications of splitting up the array like that versus doing this check every time? In effect you’d need to do that check anyway for each entry AND copy the entries to a new array. Which sounds like a net negative to me.
WDYT?
src/onCLS.ts
Outdated
| }; | ||
|
|
||
| if (softNavs(opts)) { | ||
| observe('soft-navigation', reportSoftNavCLS); |
There was a problem hiding this comment.
Followup from comment above... I think we should just automatically do this from inside the observe() helper, shared by all metrics
There was a problem hiding this comment.
Not all metrics need the soft-navigation observer (FCP and FID don’t for example as they can finalise immediately).
For those that do need this to finalise metrics that may not be finalised before then, there are different steps to make so it’s not generic across all the metrics. We could pass in a callback function to handle that, but that’s exactly what this currently does.
Also currently the observe function is for a single observer with a call back on what to do with that. I’m not sure it’s right to change that to also call another observer for some metrics, with a different callback function.
But maybe I’m just not seeing the way to do this? If you have a look at some of the other metrics and still think there’s an easier/cleaner way to do this, then definitely open to it, if you could give me a little nudge as to how you think it could be structure.
|
That’s for the review @mmocny ! I’ve cleaned it up quite a bit further so it’s a bit smaller now. Have another look if you get a chance and see what you think now. |
|
Hey! I'm super excited about this work. Could you republish the branch? |
|
Well that's embarrassing! Republished to the |
|
Thanks, that was fast. |
|
Hi @tunetheweb, Thanks a lot for introducing support for Soft Navigations in the library! While exploring the new features, I noticed something interesting. It seems that not all changes are being reported when To handle that scenario, I've slightly updated the |
|
Updated this branch to v4 code. |
Warning: This branch is likey to stay in draft for some time, and not to be merged into
mainuntil the Soft Navs experiment completesFixes #119
Implements experimental support of Soft Navigations to the library: